System and method for dynamically orchestrating application program interface trust

ABSTRACT

A system includes a purchase portal configured to receive a purchase order from a customer, wherein the purchase order includes a service from each of a plurality of service providers. When receipt of the purchase order is detected, a processor determines first and second ones of the service providers associated with the purchase order; and establishes a trust relationship between the first service provider and the second service provider in a context of the customer. The processor also sends a first request for a first trust artifact to the first service provider and a second request for a second trust artifact to the second service provider; receives the first trust artifact from the first service provider, receives the second trust artifact from the second service provider, sends the first trust artifact to the second service provider, and sends the second trust artifact to the first service provider.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to information handlingsystems, and more particularly relates to dynamically orchestratingapplication program interface trust.

BACKGROUND

As the value and use of information continue to increase, individualsand businesses seek additional ways to process and store information.One option is an information handling system. An information handlingsystem generally processes, compiles, stores, or communicatesinformation or data for business, personal, or other purposes.Technology and information handling needs and requirements can varybetween different applications. Thus, information handling systems canalso vary regarding what information is handled, how the information ishandled, how much information is processed, stored, or communicated, andhow quickly and efficiently the information can be processed, stored, orcommunicated. The variations in information handling systems allowinformation handling systems to be general or configured for a specificuser or specific use such as financial transaction processing, airlinereservations, enterprise data storage, or global communications. Also,information handling systems can include a variety of hardware andsoftware resources that can be configured to process, store, andcommunicate information and can include one or more computer systems,graphics interface systems, data storage systems, networking systems,and mobile communication systems. Information handling systems can alsoimplement various virtualized architectures. Data and voicecommunications among information handling systems may be via networksthat are wired, wireless, or some combination.

SUMMARY

A system includes a purchase portal configured to receive a purchaseorder from a customer, wherein the purchase order includes a servicefrom each of a plurality of service providers. When receipt of thepurchase order is detected, a processor determines first and second onesof the service providers associated with the purchase order; andestablishes a trust relationship between the first service provider andthe second service provider in a context of the customer. The processoralso sends a first request for a first trust artifact to the firstservice provider and a second request for a second trust artifact to thesecond service provider; receives the first trust artifact from thefirst service provider, receives the second trust artifact from thesecond service provider, sends the first trust artifact to the secondservice provider, and sends the second trust artifact to the firstservice provider.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration,elements illustrated in the Figures are not necessarily drawn to scale.For example, the dimensions of some elements may be exaggerated relativeto other elements. Embodiments incorporating teachings of the presentdisclosure are shown and described with respect to the drawings herein,in which:

FIG. 1 is a block diagram illustrating an information handling systemaccording to an embodiment of the present disclosure;

FIG. 2 is a block diagram illustrating an example of a system fordynamically orchestrating application program interface trust, accordingto an embodiment of the present disclosure;

FIG. 3 is a block diagram illustrating an example of a system foronboarding a service provider, according to an embodiment of the presentdisclosure;

FIG. 4 is a block diagram illustrating an example of a system fordynamically orchestrating application program interface trust, accordingto an embodiment of the present disclosure; and

FIG. 5 is a flowchart illustrating an example of a method fordynamically orchestrating application program interface trust, accordingto an embodiment of the present disclosure.

The use of the same reference symbols in different drawings indicatessimilar or identical items.

DETAILED DESCRIPTION OF THE DRAWINGS

The following description in combination with the Figures is provided toassist in understanding the teachings disclosed herein. The descriptionis focused on specific implementations and embodiments of the teachingsand is provided to assist in describing the teachings. This focus shouldnot be interpreted as a limitation on the scope or applicability of theteachings.

FIG. 1 illustrates an embodiment of an information handling system 100including processors 102 and 104, a chipset 110, a memory 120, agraphics adapter 130 connected to a video display 134, a non-volatileRAM (NV-RAM) 140 that includes a basic input and outputsystem/extensible firmware interface (BIOS/EFI) module 142, a diskcontroller 150, a hard disk drive (HDD) 154, an optical disk drive 156,a disk emulator 160 connected to a solid-state drive (SSD) 164, aninput/output (I/O) interface 170 connected to an add-on resource 174 anda trusted platform module (TPM) 176, a network interface 180, and abaseboard management controller (BMC) 190. Processor 102 is connected tochipset 110 via processor interface 106, and processor 104 is connectedto the chipset via processor interface 108. In a particular embodiment,processors 102 and 104 are connected via a high-capacity coherentfabric, such as a HyperTransport link, a QuickPath Interconnect, or thelike. Chipset 110 represents an integrated circuit or group ofintegrated circuits that manage the data flow between processors 102 and104 and the other elements of information handling system 100. In aparticular embodiment, chipset 110 represents a pair of integratedcircuits, such as a northbridge component and a southbridge component.In another embodiment, some or all of the functions and features ofchipset 110 are integrated with one or more of processors 102 and 104.

Memory 120 is connected to chipset 110 via a memory interface 122. Anexample of memory interface 122 includes a Double Data Rate (DDR) memorychannel and memory 120 represents one or more DDR Dual In-Line MemoryModules (DIMMs). In a particular embodiment, memory interface 122represents two or more DDR channels. In another embodiment, one or moreof processors 102 and 104 include a memory interface that provides adedicated memory for the processors. A DDR channel and the connected DDRDIMMs can be in accordance with a particular DDR standard, such as aDDR3 standard, a DDR4 standard, a DDR5 standard, or the like.

Memory 120 may further represent various combinations of memory types,such as Dynamic Random Access Memory (DRAM) DIMMs, Static Random AccessMemory (SRAM) DIMMs, non-volatile DIMMs (NV-DIMMs), storage class memorydevices, Read-Only Memory (ROM) devices, or the like. Graphics adapter130 is connected to chipset 110 via a graphics interface 132 andprovides a video display output 136 to a video display 134. An exampleof a graphics interface 132 includes a Peripheral ComponentInterconnect-Express (PCIe) interface and graphics adapter 130 caninclude a four lane (×4) PCIe adapter, an eight lane (×8) PCIe adapter,a 16-lane (×16) PCIe adapter, or another configuration, as needed ordesired. In a particular embodiment, graphics adapter 130 is provideddown on a system printed circuit board (PCB). Video display output 136can include a Digital Video Interface (DVI), a High-DefinitionMultimedia Interface (HDMI), a DisplayPort interface, or the like, andvideo display 134 can include a monitor, a smart television, an embeddeddisplay such as a laptop computer display, or the like.

NV-RAM 140, disk controller 150, and I/O interface 170 are connected tochipset 110 via an I/O channel 112. An example of I/O channel 112includes one or more point-to-point PCIe links between chipset 110 andeach of NV-RAM 140, disk controller 150, and I/O interface 170. Chipset110 can also include one or more other I/O interfaces, including anIndustry Standard Architecture (ISA) interface, a Small Computer SerialInterface (SCSI) interface, an Inter-Integrated Circuit (I²C) interface,a System Packet Interface (SPI), a Universal Serial Bus (USB), anotherinterface, or a combination thereof. NV-RAM 140 includes BIOS/EFI module142 that stores machine-executable code (BIOS/EFI code) that operates todetect the resources of information handling system 100, to providedrivers for the resources, to initialize the resources, and to providecommon access mechanisms for the resources. The functions and featuresof BIOS/EFI module 142 will be further described below.

Disk controller 150 includes a disk interface 152 that connects the disccontroller to a hard disk drive (HDD) 154, to an optical disk drive(ODD) 156, and to disk emulator 160. An example of disk interface 152includes an Integrated Drive Electronics (IDE) interface, an AdvancedTechnology Attachment (ATA) such as a parallel ATA (PATA) interface or aserial ATA (SATA) interface, a SCSI interface, a USB interface, aproprietary interface, or a combination thereof. Disk emulator 160permits SSD 164 to be connected to information handling system 100 viaan external interface 162. An example of external interface 162 includesa USB interface, an institute of electrical and electronics engineers(IEEE) 1394 (Firewire) interface, a proprietary interface, or acombination thereof. Alternatively, SSD 164 can be disposed withininformation handling system 100.

I/O interface 170 includes a peripheral interface 172 that connects theI/O interface to add-on resource 174, to TPM 176, and to networkinterface 180. Peripheral interface 172 can be the same type ofinterface as I/O channel 112 or can be a different type of interface. Assuch, I/O interface 170 extends the capacity of I/O channel 112 whenperipheral interface 172 and the I/O channel are of the same type, andthe I/O interface translates information from a format suitable to theI/O channel to a format suitable to the peripheral interface 172 whenthey are of a different type. Add-on resource 174 can include a datastorage system, an additional graphics interface, a network interfacecard (NIC), a sound/video processing card, another add-on resource, or acombination thereof. Add-on resource 174 can be on a main circuit board,on separate circuit board or add-in card disposed within informationhandling system 100, a device that is external to the informationhandling system, or a combination thereof.

Network interface 180 represents a network communication device disposedwithin information handling system 100, on a main circuit board of theinformation handling system, integrated onto another component such aschipset 110, in another suitable location, or a combination thereof.Network interface 180 includes a network channel 182 that provides aninterface to devices that are external to information handling system100. In a particular embodiment, network channel 182 is of a differenttype than peripheral interface 172 and network interface 180 translatesinformation from a format suitable to the peripheral channel to a formatsuitable to external devices.

In a particular embodiment, network interface 180 includes a NIC or hostbus adapter (HBA), and an example of network channel 182 includes anInfiniBand channel, a Fibre Channel, a Gigabit Ethernet channel, aproprietary channel architecture, or a combination thereof. In anotherembodiment, network interface 180 includes a wireless communicationinterface, and network channel 182 includes a Wi-Fi channel, anear-field communication (NFC) channel, a Bluetooth orBluetooth-Low-Energy (BLE) channel, a cellular based interface such as aGlobal System for Mobile (GSM) interface, a Code-Division MultipleAccess (CDMA) interface, a Universal Mobile Telecommunications System(UMTS) interface, a Long-Term Evolution (LTE) interface, or anothercellular based interface, or a combination thereof. Network channel 182can be connected to an external network resource (not illustrated). Thenetwork resource can include another information handling system, a datastorage system, another network, a grid management system, anothersuitable resource, or a combination thereof.

BMC 190 is connected to multiple elements of information handling system100 via one or more management interface 192 to provide out of bandmonitoring, maintenance, and control of the elements of the informationhandling system. As such, BMC 190 represents a processing devicedifferent from processor 102 and processor 104, which provides variousmanagement functions for information handling system 100. For example,BMC 190 may be responsible for power management, cooling management, andthe like. The term BMC is often used in the context of server systems,while in a consumer-level device a BMC may be referred to as an embeddedcontroller (EC). A BMC included at a data storage system can be referredto as a storage enclosure processor. A BMC included at a chassis of ablade server can be referred to as a chassis management controller andembedded controllers included at the blades of the blade server can bereferred to as blade management controllers. Capabilities and functionsprovided by BMC 190 can vary considerably based on the type ofinformation handling system. BMC 190 can operate in accordance with anIntelligent Platform Management Interface (IPMI). Examples of BMC 190include an Integrated Dell® Remote Access Controller (iDRAC).

Management interface 192 represents one or more out-of-bandcommunication interfaces between BMC 190 and the elements of informationhandling system 100, and can include an Inter-Integrated Circuit (I2C)bus, a System Management Bus (SMBUS), a Power Management Bus (PMBUS), aLow Pin Count (LPC) interface, a serial bus such as a Universal SerialBus (USB) or a Serial Peripheral Interface (SPI), a network interfacesuch as an Ethernet interface, a high-speed serial data link such as aPeripheral Component Interconnect-Express (PCIe) interface, a NetworkController Sideband Interface (NC-SI), or the like. As used herein,out-of-band access refers to operations performed apart from aBIOS/operating system execution environment on information handlingsystem 100, that is apart from the execution of code by processors 102and 104 and procedures that are implemented on the information handlingsystem in response to the executed code.

BMC 190 operates to monitor and maintain system firmware, such as codestored in BIOS/EFI module 142, option ROMs for graphics adapter 130,disk controller 150, add-on resource 174, network interface 180, orother elements of information handling system 100, as needed or desired.In particular, BMC 190 includes a network interface 194 that can beconnected to a remote management system to receive firmware updates, asneeded or desired. Here, BMC 190 receives the firmware updates, storesthe updates to a data storage device associated with the BMC, transfersthe firmware updates to NV-RAM of the device or system that is thesubject of the firmware update, thereby replacing the currentlyoperating firmware associated with the device or system, and rebootsinformation handling system, whereupon the device or system utilizes theupdated firmware image.

BMC 190 utilizes various protocols and application programminginterfaces (APIs) to direct and control the processes for monitoring andmaintaining the system firmware. An example of a protocol or API formonitoring and maintaining the system firmware includes a graphical userinterface (GUI) associated with BMC 190, an interface defined by theDistributed Management Taskforce (DMTF) (such as a Web ServicesManagement (WSMan) interface, a Management Component Transport Protocol(MCTP) or, a Redfish® interface), various vendor defined interfaces(such as a Dell EMC Remote Access Controller Administrator (RACADM)utility, a Dell EMC OpenManage Server Administrator (OMSS) utility, aDell EMC OpenManage Storage Services (OMSS) utility, or a Dell EMCOpenManage Deployment Toolkit (DTK) suite), a BIOS setup utility such asinvoked by a “F2” boot option, or another protocol or API, as needed ordesired.

In a particular embodiment, BMC 190 is included on a main circuit board(such as a baseboard, a motherboard, or any combination thereof) ofinformation handling system 100 or is integrated onto another element ofthe information handling system such as chipset 110, or another suitableelement, as needed or desired. As such, BMC 190 can be part of anintegrated circuit or a chipset within information handling system 100.An example of BMC 190 includes an iDRAC, or the like. BMC 190 mayoperate on a separate power plane from other resources in informationhandling system 100. Thus BMC 190 can communicate with the managementsystem via network interface 194 while the resources of informationhandling system 100 are powered off. Here, information can be sent fromthe management system to BMC 190 and the information can be stored in aRAM or NV-RAM associated with the BMC. Information stored in the RAM maybe lost after power-down of the power plane for BMC 190, whileinformation stored in the NV-RAM may be saved through apower-down/power-up cycle of the power plane for the BMC.

Information handling system 100 can include additional components andadditional busses, not shown for clarity. For example, informationhandling system 100 can include multiple processor cores, audio devices,and the like. While a particular arrangement of bus technologies andinterconnections is illustrated for the purpose of example, one of skillwill appreciate that the techniques disclosed herein are applicable toother system architectures. Information handling system 100 can includemultiple CPUs and redundant bus controllers. One or more components canbe integrated together. Information handling system 100 can includeadditional buses and bus protocols, for example, I2C and the like.Additional components of information handling system 100 can include oneor more storage devices that can store machine-executable code, one ormore communications ports for communicating with external devices, andvarious input and output (I/O) devices, such as a keyboard, a mouse, anda video display.

For purpose of this disclosure information handling system 100 caninclude any instrumentality or aggregate of instrumentalities operableto compute, classify, process, transmit, receive, retrieve, originate,switch, store, display, manifest, detect, record, reproduce, handle, orutilize any form of information, intelligence, or data for business,scientific, control, entertainment, or other purposes. For example,information handling system 100 can be a personal computer, a laptopcomputer, a smartphone, a tablet device or other consumer electronicdevice, a network server, a network storage device, a switch, a router,or another network communication device, or any other suitable deviceand may vary in size, shape, performance, functionality, and price.Further, information handling system 100 can include processingresources for executing machine-executable code, such as processor 102,a programmable logic array (PLA), an embedded device such as aSystem-on-a-Chip (SoC), or other control logic hardware. Informationhandling system 100 can also include one or more computer-readable mediafor storing machine-executable code, such as software or data.

“Cloud computing” is a model for delivering hosted services over theinternet. The hosted services fall into different categories, forexample: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service(PaaS) and Software-as-a-Service (SaaS). These hosted services may beavailable for purchase at a marketplace where individuals andenterprises pose as buyers or customers and independent service vendorsor service providers as sellers. The hosted services may be bundled andsold as a better-together solution. The customers may also pick andchoose a set of hosted services and put together their own solutionbased on what hosted services are available in the marketplace. Whenbought as part of the solution, the service providers may integrate witheach other using APIs that are protected using tokens and/or sharedsecrets. Typically, an administrator acting on behalf of the customer isresponsible for setting up or establishing trust between these serviceproviders. The trust may be established through a manual creation and/orcopy-paste of identifiers and secrets, and/or uploading and downloadingof certificates, into at least one of the service providers or at acentral administration dashboard. Such process is time consuming, proneto errors, and potentially exposes sensitive information through theadministrator's browser, keyboard or email system. Thus, there is a needfor a facilitator such as a central trust orchestrator to automaticallyset up exchanges of trust artifacts such as public key certificates,between the various bundled service providers for each one of thecustomers.

FIG. 2 illustrates a system 200 for orchestrating API trusts betweenservice providers. System 200 includes customers 205 a-205 n, a network210, a cloud services management system 230, and service providers 280a-280 n, wherein each one may be similar to information handling system100. Cloud services management system 230 includes a customer portal235, a trust orchestrator 240, a storage 265, and a hardware securitymodule (HSM) 270. Trust orchestrator 240 includes a customer portalinterface 245, a security interface 250, a trust and security module255, and an onboarding module 260.

Customers 205 a-205 n, service providers 280 a-280 n, and cloud servicesmanagement system 230 may be communicatively coupled via a network 210.In one embodiment, network 210 may include the internet. Alternatively,network 210 may include a public or private cloud servicesinterconnection network. Network 210 may include various network traffichandling devices, including routers, switches, data security devices,firewalls, service controllers, network interface devices, or the like.The devices may be configured to facilitate communications betweencustomers 205 a-205 n, service providers 280 a-280 n, and cloud servicesmanagement system 230.

Cloud services management system 230 may include one or more informationhandling systems similar to information handling system 100. Cloudservices management system 230 may be an online storefront ormarketplace that allows customers to purchase cloud-based services andapplications such as Dell Technologies Unified Workspace™, Amazon WebServices® (AWS), Microsoft Azure®, or similar. The cloud-based servicesand applications may be provided by third-party independent softwarevendors also referred to as service providers. The services provided bythese service providers may be accessed via APIs. Accordingly, acustomer may purchase one or more solutions from service providers thatare in partnerships with cloud services management system 230. Afterpurchase of the solution, the customer may be operational across theservice providers without any customer setup.

In such a marketplace, customer portal 235 may be configured to allow acustomer such as customer 205 a to purchase a service or a solution,wherein the solution may include one or more services and/orapplications from a service provider or a set of service providers.Customer portal 235 may maintain a listing of solutions, serviceproviders, and its applications and/or services that customer 205 a maychoose from. Customer 205 a may be an enterprise or a user associatedwith the enterprise.

Using customer portal 235, customer 205 a, for example, can submit apurchase order such as purchase order 215 to purchase a bundle or set ofservices offered by service providers 280 a-280 n. For example, aservice provider offering event detection and response services could bebundled and purchased together with another service provider that offersendpoint encryption services. In particular, customer 205 a may purchasea solution that includes services from Carbon Black Cloud™ andCrowdStrike® for example. By bundling the services, customer 205 a canavail of a solution that would be able to restrict access to theendpoint encryption keys if a threat is detected on a computer in thecustomer's network without figuring out how to make the services worktogether. In an embodiment, customer 205 a may submit a purchase order215 to purchase a particular solution which may include servicesprovided by service provider 280 a and service provider 280 b.Similarly, another customer, such as customer 205 b, can submit purchaseorder 220 to purchase another solution which may include servicesprovided by service provider 280 b and service provider 280 n. Thepurchase order may include one or more solutions; each solution may havea different stock keeping unit (SKU). Each SKU may include one or moreservice providers.

Service providers 280 a-280 n may include telecommunications serviceproviders, application service providers, storage service provides,internet service providers, etc. A service provider that decides to forma partnership with cloud services management system 230 may need toestablish a trust relationship with trust orchestrator 240. Also, theservice provider may be directed to implement a web API defined by cloudservices management system 230 or trust orchestrator 240 in particular.This process may also be referred to as an onboarding process performedtypically once by the service provider. The onboarding process may beperformed by onboarding module 260. Once onboarded, the service providermay be listed and available for purchase by the customer via customerportal 235.

When purchased as part of a solution, a service provider may need towork together with the other service providers included in the solution.To work together, trust orchestrator 240 may need to establish trustbetween service providers 280 a-280 n. By default, a service providerdoes not trust another service provider. For example, one serviceprovider doesn't have permission to use the resources and/or services ofanother service provider. For the one service provider to havepermission to use the resources and/or services of the other serviceprovider, the service provides may need to trust each other.

In an embodiment, a purchase order of a solution with services from oneor more service providers may trigger a programmatic establishment oftrust which includes the exchange of trust artifacts between the serviceproviders associated with the purchase order. These programmaticexchanges of trust artifacts are performed dynamically by cloud servicesmanagement system 230 or trust orchestrator 240 in particular on behalfof the customer. Thus, the customer has no further involvement after thepurchase.

The established trust is specifically in the context of the customerwhich purchased the solution. For example, if customer 205 a purchased asolution with services from service provider 280 a and service provider280 b, the established trust is associated with customer 205 a. Serviceprovider 280 a and service provider 280 b may not trust each otheroutside of this context. If customer 205 b purchased the same solution,service provider 280 a and service provider 280 b may have to performthe same programmatic exchange or artifacts in the context of customer205 b. On the other hand, if customer 205 a purchases additional seatsof the same solution purchased earlier, the additional seats may notneed to perform the programmatic exchange and would just beautomatically “lit up” or available for use by the customer.

The service providers communicate through defined web APIs andspecifications such as Hypertext Transfer Protocol (HTTP). Due to theopen nature of the web, these services need to verify the HTTP requestsmade into their systems to make sure that they are authorized. A way tosecure the APIs is to include a trust artifact such as a signed tokenlike a JavaScript Object Notation (JSON) Web Token (JWT) in the HTTPrequest. An API caller, which is the entity that sends the request, suchas trust orchestrator 240 or one of service providers 280 a-280 n maygenerate, encrypt, and/or sign the token with a secret, a public key ofa digital certificate such as an X.509 certificate. The API receiver,which is the entity that receives the request such as trust orchestrator240 or the other one of service providers 280 a-280 n, may verify thesignature before processing the API request. Private information such asa private key does not leave the security boundary of the issuingservice provider. If the trust orchestrator generates the private keysuch as during the onboarding process, the trust orchestrator stores theprivate key in a secure storage such as HSM 270.

Trust orchestrator may be configured as a central trust facilitatorbetween service providers 280 a-280 n for customers 205 a-205 n. Suchthat trust orchestrator 240 automatically sets up exchanges ofidentifiers, tokens, and/or trust artifacts such as public-keycertificates, between the service providers on behalf of the customer.Trust orchestrator 240 may be a complementary system to a purchase orderportal such as customer portal 235, or on its own. Prior to facilitatingthese exchanges, the service providers may be needed to establish apartnership with cloud services management system 230 or trustorchestrator 240 in particular. This may also be referred to as anonboarding process and is performed once for each service provider. Fromthat point, trust orchestrator 240 can programmatically establish trustbetween one of the onboarded service providers with another one of theonboarded service providers on the customer's behalf. Unless referred toas an un-onboarded service provider, service providers in the currentdisclosure such as service providers 280 a-280 n have been onboarded.Trust orchestrator 240 establishes the API trust using trust artifactsor tokens from a service provider and sends them to another serviceprovider involved in the exchange. The API trust provides a securechannel of communication between the service providers.

A trust artifact may be an object, a data structure or the like thatincludes at least enough of the information needed for a serviceprovider to access the services or content of another service providersuch as a domain name system or URL of the service provider. The trustartifact may also include instructions for trust orchestrator 240 and/orthe service providers on how to communicate with its issuing entity.Trust artifacts may include digital certificates such as an X.509certificate, a public key, and a shared token, or similar.

Subsequent to the onboarding process, requests/responses or API callsbetween trust orchestrator 240 and service providers 280 a-280 n aresecured. The tokens may be signed by a private key of the requestor orAPI caller. For example, HTTP requests made by trust orchestrator 240 toa particular service provider are signed by a service provider specificX.509 certificate private key generated by trust orchestrator 240 duringthe onboarding process. Trust orchestrator 240 stores the X.509certificate private key in the secured storage such as HSM 270.

Trust orchestrator 240 may be configured to monitor the expiration ofthe tokens, digital certificates, private/public key pairs, or othertrust artifacts. Also, trust orchestrator 240 may also be configured torequest another trust artifact to replace the trust artifact in casesthat the original trust artifact is no longer valid. The replacementtrust artifact is used to re-stablish the trust between the serviceproviders 280 a-280 n and/or trust orchestrator 240. For example, trustorchestrator 240 may request another digital certificate to replace anexpired digital certificate of service provider 280 a. Further, trustorchestrator 240 may also be configured to monitor revocation of thedigital certificates and/or to dynamically replace revoked digitalcertificates. Certificate revocation is the action of declaring acertificate invalid before the end of its validity period.

As illustrated, in some embodiments, trust orchestrator 240 may includea trust and security module 255. Trust and security module 255 may beconfigured to ensure that service providers 280 a-280 b are properlyauthenticated and/or trusted such that the customer that bought or optedfor a set of service providers may be able to receive services from theservice providers. As each service provider may prefer a different trustartifact, trust and security module 255 may determine the appropriatetrust artifact. For example, trust and security module 255 may querystorage 265 to determine what information is needed by a particularservice provider for the trust exchange. For example, storage 265 mayinclude a database that stores the information in one or more tablessuch as table 275, table 285, table 290, and table 295. The informationmay be then provided to trust orchestrator 240 and/or the serviceprovider. The tables shown in FIG. 2 are for illustration purposes onlyand do not limit the current disclosure. The database may include more,less, or different tables than currently shown.

Also, trust orchestrator may also include a security interface 250.Security interface 250 may be configured to ensure that serviceproviders 280 a-280 n utilize the correct authorization/authenticationmechanism when communicating with each other or trust orchestrator 240.Security interface 250 may query storage 265 and/or trust orchestrator240 to determine the preferred authorization/authentication mechanism.For example, a particular service provider may prefer to use basic orbearer authentication tokens. In another embodiment, cloud servicesmanagement system 230 may provide service providers 280 a-280 n withinstructions on how to communicate with trust orchestrator 240 and/orwith each other within the security context of a particular customer.For example, cloud services management system 230 or trust orchestrator240, in particular, may provide service providers 280 a-280 n with APIsfor services providers 280 a-280 n to implement during the onboardingprocess.

Although illustrated as a single entity, trust orchestrator 240 can beimplemented in a distributed computing environment where tasks areperformed by local and remote processing devices that are linked, eitherby hardwired links, wireless links, or by a combination of hardwired andwireless links, through a communication network. Trust orchestratorand/or its components may be comprised of software, hardware, or anycombination of software and hardware as circumstances warrant.

Storage 265 may be configured to store information that may be used tofacilitate the programmatic trust exchanges and/or other information ortransactions between cloud services management system 230, enterprises205 a-205 n, and service providers 280 a-280 n. For example, storage 265may include information regarding how the service providers want tocommunicate and/or exchange trust artifacts which may be used by trustorchestrator 240 when facilitating the trust relationships between theservice providers. Storage 265 may include other information such assolutions ordered by each enterprise, validity date ranges of the trustartifacts if any, information associated with the onboarded serviceproviders, solutions offered by cloud services management system 230,etc. Storage 265 can be any form of persistent storage and can beconfigured to store different types of data. Storage 265 can include anHDD, a single magnetic recording (SMR) drive, a rewritable optical diskdrive (ODD), a solid-state drive (SSD) other types of readable andwritable storage media, or a combination thereof. The information may bestored in storage 265 using a database or a flat-file system.

FIG. 3 illustrates a system 300 for onboarding a service provider thatincludes establishing a partnership and/or trust between a trustorchestrator and the service provider. System 300 is similar to system200 and includes a user 305, a trust orchestrator 310 and a serviceprovider 315. During the onboarding process, service provider 315implements a set of APIs so that it is call-able from trust orchestrator310 which are validated by the recipient using a public key of thesender. Also, a set of public X.509 certificates may be exchangedbetween trust orchestrator 310 and service provider 315 to establish atrust orchestrator-vendor or orchestrator-service provider trust.

User 305 may be an administrator, an operations specialist, or similarthat may be authorized to initiate an onboarding process between trustorchestrator 310 and service provider 315. Similar to service providers280 a-280 n, service provider 315 may be an independent software vendor.Trust orchestrator 310 may onboard service provider 315 outside thecontext of any customer.

FIG. 3 is annotated with a series of letters A-E. Each of these lettersrepresents a stage of one or more operations. Although these stages areordered for this example, the stages illustrate one example to aid inunderstanding this disclosure and should not be used to limit theclaims. Subject matter falling within the scope of the claims can varywith respect to the order of the operations.

At stage A, user 305 transmits a request to trust orchestrator 310 toonboard service provider 315. As used herein, onboarding is a process toadd a particular software vendor as one of the trusted softwareproviders by trust orchestrator 310. Various methodologies may be usedto transmit the onboarding request such as via an application, a webservice, an interface, etc. In particular, the request may be arepresentation state transfer (REST) API request, an HTTP request, acommand-line interface (CLI) request, a graphical user interface (GUI),etc. The request may include information that identifies user 305,service provider 315 and/or attributes associated with user 305 and/orservice provider 315. For example, the request may include a useridentifier, a service provider identifier, a certificate associated withthe user, a certificate associated with the service provider, a uniformresource locator that can be used to access the service provider, aninternet protocol address of the service provider, etc.

At stage B, trust orchestrator 310 may generate an asymmetric key pairspecific to each service provider to be onboarded. The asymmetric keypair to be used in establishing trusts with each service provider. Forexample, trust orchestrator 310 may generate a private/publiccryptographic key pair for service provider 315 which will be used bytrust orchestrator 310 to sign each communication with service provider315. This protects against accidental cross-service providercommunication. Further, this ensures that the revocation of anasymmetric key certificate of one service provider does not affectanother service provider.

Trust orchestrator 310 may act as a certificate authority and generate apublic key infrastructure (PKI) certificate such as an X.509 certificatespecific for service provider 315. The PKI certificate is a digitalcertificate, which is a signed object or data structure, issued based ona pair of cryptographic keys that form a unique credential associatedwith a user or organization such as trust orchestrator 310. The PKIcertificate may include information that identifies trust orchestrator310 and/or service provider 315, such as a service provider identifier,a service provider name, etc. The PKI certificate may also include aserial number, an object identifier that specifies the algorithm used tosign the certificate, a validity period of the PKI certificate, a publickey associated with service provider 315, a name and/or identifier ofthe issuer, etc. In another embodiment, trust orchestrator 310 mayrequest a trusted certificate authority to issue the PKI certificate forservice provider 315 on its behalf.

At stage C, trust orchestrator 310 transmits a request such as an HTTPrequest to establish trust between trust orchestrator 310 and serviceprovider 315, also referred herein as orchestrator trust. Trustorchestrator 310 may provide its public key or a digital certificatewith the request. At stage D, in response to the received request,service provider 315 generates a digital certificate also referred to asa PKI certificate such as an X.509 certificate to be used inestablishing trust with trust orchestrator 310. At stage E, serviceprovider 315 sends a response such as an HTTP response to trustorchestrator 310 that includes a public key or the digital certificateof service provider 315 to trust orchestrator 310.

FIG. 4 illustrates a system 400 for establishing trust between serviceproviders in the context of a customer. System 400 is similar to system200 of FIG. 2 and includes a customer portal 405, trust orchestrator310, service provider 315, and a service provider 410. FIG. 4 isannotated with a series of letters A-G. Each of these letters representsa stage of one or more operations. Although these stages are ordered forthis example, the stages illustrate one example to aid in understandingthis disclosure and should not be used to limit the claims. Subjectmatter falling within the scope of the claims can vary with respect tothe order of the operations.

At stage A, trust orchestrator 310 may receive a trigger or a request toestablish service-to-service trust for the customer. For example, thecustomer may submit a purchase order that includes a solution withservices from one or more service providers. Successfully processing thepurchase order may trigger a request to the trust orchestrator toestablish the service-to-service trust between the service providersassociated with the purchase order. Various methodologies may be used totransmit the request such as via an application, a web service, aninterface, etc. In particular, the request may be a REST API request, anHTTP request, a CLI request, a GUI, etc.

For example, the solution may include an independent service vendor,like service provider 315, which provides event detection and responseservices. The solution may include another independent service vendor,like service provider 415, which provides endpoint encryption. The twoindependent service vendors may need to cooperate and trust each otherso that the customer can successfully utilize their services. Forexample, the customer may want to restrict access to endpoint encryptionkeys if a threat is detected on one of the information handling systemsin the customer's environment. Thus, it is important to establish trustbetween the aforementioned independent service vendors.

At stage B, trust orchestrator 310 may send a request to serviceprovider 315 for a trust artifact such as an X.509 certificate on behalfof the customer and/or service provider 410. For example, trustorchestrator 310 may send a REST API request, an HTTP request or similarto service provider 315. The request may use a token such as a JSON webtoken to transmit the information in a JSON object for example. Theinformation may be digitally signed using a secret such as a publiccryptographic key with a message authentication code like a hash-basedmessage authentication code (HMAC) algorithm or Rivest-Shamir-Adleman(RSA) or elliptic curve digital signature algorithm (ECDSA)cryptosystem. When the token is digitally signed using a public key, thesignature certifies that the party holding the private key is the onethat signed it. Additionally, the signature may be calculated using therequest's header and payload, which the receiver can use to verify thatthe content of the request has not been tampered with. For example, thesignature may be a JSON web signature that is calculated using theSHA256 algorithm with an RSA key length of 4096 bits.

At stage C, trust orchestrator 310 may send a similar request to serviceprovider 410 for a trust artifact such as an X.509 certificate on behalfof the customer and/or service provider 315. For example, trustorchestrator 310 sends a REST API request, an HTTP request or similar toservice provider 410. Similar to stage B, the trust orchestrator maysign the request.

At stage D, service provider 315 may send a response to the receivedrequest. For example service provider 315 sends a REST API response, anHTTP response or similar to trust orchestrator 310. The response mayinclude the trust artifact as requested by trust orchestrator 310. Inanother embodiment, the response may include a software component, aservice moniker or an object that states that the request has beenaccepted and will be processed asynchronously. The software component,the service moniker, or the object may include a time frame of when thetrust artifact may be sent to trust orchestrator 310. Trust orchestrator310 may send a query to service provider 315 that includes the softwarecomponent, the service moniker, or the object if trust orchestrator 310has not received the trust artifact from service provider 315 within thedesignated time frame.

At stage E, service provider 410 may send a response to the receivedrequest. For example, service provider 410 may send a REST API response,an HTTP response, or similar to trust orchestrator 310. Similar to stageD, the response may include the trust artifact as requested by trustorchestrator 310. In another embodiment, the response may include asoftware component, a service moniker, or an object that states that therequest has been accepted and will be processed asynchronously. Thesoftware component, the service moniker, or the object may include atime frame of when the trust artifact may be sent to trust orchestrator310. Trust orchestrator 310 may send a query to service provider 410that includes the software component, the service moniker, or the objectif trust orchestrator 310 has not received the trust artifact fromservice provider 410 within the designated time frame.

At stage F, trust orchestrator 310 may send the trust artifact ofservice provider 410 to service provider 315. For example, trustorchestrator 310 may send a X.509 certificate of service provider 410with its public key to service provider 315. At stage G, trustorchestrator 310 may send the trust artifact of service provider 315 toservice provider 410. For example, trust orchestrator 310 sends theX.509 certificate of service provider 315 with its public key to serviceprovider 410. The exchange of trust artifacts allows service provider315 to trust service provider 410 and service provider 410 to trustservice provider 315. Service provider 315 and service provider 410 maythen communicate with a secure channel using the public keys.

Stages A through F may be performed by trust orchestrator 310 withservice provider 315 and another service provider on behalf of thecustomer. For example, if there is a service provider 415 that is alsoassociate by the trigger in addition to service provider 410, the trustorchestrator will facilitate another exchange of trust artifacts in thecontext of the customer between service provider 315 and serviceprovider 415.

FIG. 5 illustrates a method 500 for dynamically orchestratingapplication program interface trust between service providers byexchanging trust artifacts. The method 500 may be performed by one ormore components of FIG. 2 . The method 500 typically starts at block 505where a trust orchestrator receives a trigger to establishservice-to-service trust between service providers. The trigger, alsoreferred to as a triggering event, may be a purchase of a solution by acustomer, a revocation or expiration of a digital certification, arequest by an administrator, etc. In one embodiment, a customer portalafter a successful purchase by a customer, such as successful payment ofthe purchase order, may trigger a customer portal interface in the trustorchestrator to initiate the service-to-service trust on behalf of thecustomer by submitting a request. In another embodiment, the customerportal interface may detect the triggering event without the customerportal submitting the request. In yet another embodiment, a trust andsecurity module that monitors expiration dates and/or revocation statusof trust artifacts such as digital certificates may trigger theservice-to-service trust upon determining that a trust artifact is nolonger valid, such as when the trust artifact is expired and/or revoked.The method proceeds to block 510.

At block 510, the method identifies one or more service providersassociated with the triggering event. The triggering event may includeidentifiers of the service providers. For example, the expired orrevoked digital certificate may include the identifier of the serviceprovider that generated the digital certificate. In another embodiment,the trust processor may query a database for the service providersassociated with the triggering event. For example, the purchase orderassociated with the purchase of the solution by the customer may includea solution SKU. The trust orchestrator may determine the serviceproviders by querying a database table such as table 290 and/or table295 of FIG. 2 . The method may generate a data structure such as a listof the identified service providers. The method proceeds to process eachservice provider at block 515. The method may traverse through the datastructure according to an order such as the service provider identifier.The service provider being processed may be referred to as the currentservice provider. The method proceeds to decision block 520.

At decision block 520, a decision is made on whether the current serviceprovider has been onboarded. If the current service provider has beenonboarded, then the “YES” branch of decision block 520 is taken and themethod proceeds to decision block 530. If the current service providerhas not been onboarded, then the “NO” branch of decision block 520 istaken and the method proceeds to decision block 525. At block 525, themethod may submit a notification such as a failure event that thecurrent service provider has not been onboarded. After submitting thenotification, the method ends.

At decision block 530, a decision is made on whether the onboardingcredential of the current service provider is still valid. Theonboarding credential may be a trust artifact submitted by the serviceprovider to the trust orchestrator during the onboarding process. Thetrust artifact may be a digital certificate, a token, or similar. Theonboarding credential may be the private/public key pair generated bythe trust orchestrator during the onboarding process. If the onboardingcredential of the current service provider is still valid, then the“YES” branch of decision block 530 is taken and the method proceeds toblock 540. If the onboarding credential of the current service provideris not valid, then the “NO” branch of decision block 530 is taken andthe method proceeds to block 535 where the onboarding credential of thecurrent service provider is renewed. For example, the trust orchestratorsends a request for a replacement onboarding credential to the serviceprovider. Upon receipt of a valid replacement for the onboardingcredential the method proceeds to block 540. The requests and/orresponses in method 500 may be based on authorized APIrequests/responses between the trust processor and the service providersand/or between each of the service providers. The authorized APIrequests/responses may be determined during the onboarding process ofeach of the service providers.

At block 540, the method identifies the other service providersassociated with the trigger. The method may identify the other serviceproviders based on the service providers identified in block 510. Afteridentifying the other service providers, the method may generate a datastructure such as a list of the identified other service providers. Themethod proceeds to process each service provider at block 545 where themethod may traverse through the data structure according to an ordersuch as the service provider identifier. The current method beingprocessed may be referred to as the current other service provider. Themethod proceeds to block 550.

At block 550, the method requests a trust artifact from the currentother service provider. If the trigger is associated with a customer oran enterprise the method requests the trust artifact on behalf of thecustomer or the enterprise associated with the trigger. For example, thetrigger may be a purchase order from the customer or the enterprise. Thetrust artifact may be a secret, a web token, a digital certificate suchas an X.509 certificate or similar. After sending the request, themethod proceeds to block 545. In another embodiment, if the method justreceived a replacement onboarding credential from block 540 and thereplacement onboarding credential is the same as the trust artifact, themethod proceeds to block 555.

At block 555, the method receives the requested trust artifact from thecurrent other service provider. The method may verify the validityand/or authenticity of the received trust artifact before proceeding toblock 560. At block 560, the method sends the trust artifact of thecurrent service provider to the current other service provider. As suchthis is an exchange of trust artifacts between the current serviceprovider and the current other service provider on behalf of thecustomer or the enterprise. Because the exchange of trust artifactsbetween service providers is in the context of the customer or theenterprise, the trust artifacts exchanged between the current serviceprovider and the current other service provider is distinct from thetrust artifacts exchanged between the current service provider and anext other service provider, wherein the current other service provideris distinct from the next other service provider. After sending thetrust artifact to the current other service provider, the methodproceeds to block 565, where the method determines whether there isanother current other service provider to be processed. If there isanother current other service provider to be processed, then the “YES”branch of block 565 is taken and the method proceeds to block 545. Ifthere no current other service provider to be processed, then the “NO”branch of block 565 is taken and the method proceeds to block 570.

At block 570, the method determines whether there is another currentservice provider to be processed. If there is another current serviceprovider to be processed, then the “YES” branch of block 570 is takenand the method proceeds to block 515. If there no current serviceprovider to be processed, then the “NO” branch of block 570 is taken andthe method ends.

Although FIG. 5 show example blocks of method 500 in someimplementation, method 500 may include additional blocks, fewer blocks,different blocks, or differently arranged blocks than those depicted inFIG. 5 . Additionally, or alternatively, two or more of the blocks ofmethod 500 may be performed in parallel. For example, the inner loopwhich includes block 545 through block 565 may be performed in parallel.In particular, a different thread may be generated for each one of thecurrent other service provider to be processed.

In accordance with various embodiments of the present disclosure, themethods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedembodiment, implementations can include distributed processing,component/object distributed processing, and parallel processing.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionalities as describedherein.

The present disclosure contemplates a computer-readable medium thatincludes instructions or receives and executes instructions responsiveto a propagated signal; so that a device connected to a network cancommunicate voice, video or data over the network. Further, theinstructions may be transmitted or received over the network via thenetwork interface device.

While the computer-readable medium is shown to be a single medium, theterm “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium can be arandom-access memory or other volatile re-writable memory. Additionally,the computer-readable medium can include a magneto-optical or opticalmedium, such as a disk or tapes or another storage device to storeinformation received via carrier wave signals such as a signalcommunicated over a transmission medium. A digital file attachment to ane-mail or other self-contained information archive or set of archivesmay be considered a distribution medium that is equivalent to a tangiblestorage medium. Accordingly, the disclosure is considered to include anyone or more of a computer-readable medium or a distribution medium andother equivalents and successor media, in which data or instructions maybe stored.

Although only a few exemplary embodiments have been described in detailabove, those skilled in the art will readily appreciate that manymodifications are possible in the exemplary embodiments withoutmaterially departing from the novel teachings and advantages of theembodiments of the present disclosure. Accordingly, all suchmodifications are intended to be included within the scope of theembodiments of the present disclosure as defined in the followingclaims. In the claims, means-plus-function clauses are intended to coverthe structures described herein as performing the recited function andnot only structural equivalents but also equivalent structures.

What is claimed is:
 1. A method comprising: determining, by a processor,a plurality of service providers associated with a purchase order of acustomer; for each one of the service providers, establishing trustbetween the service providers on behalf of the customer that includesexchanging of trust artifacts, wherein the exchanging of the trustartifacts includes sending a request to each of the service providersfor a respective trust artifact, receiving the respective trust artifactfrom each of the service providers and sending the respective trustartifact to other service providers; and subsequent to the establishingtrust between the service providers, sending a particular request by afirst service provider to a second service provider, wherein theparticular request is signed by a particular private key of the firstservice provider, wherein the second service provider uses a particularpublic key of the first service provider to verify authenticity of theparticular request.
 2. The method of claim 1, wherein the serviceproviders were onboarded by the processor prior to the purchase order.3. The method of claim 1, wherein the trust artifacts include digitalcertificates.
 4. The method of claim 1, wherein the purchase order ofthe customer is a triggering event for the determining the serviceproviders associated with the purchase order.
 5. The method of claim 1,wherein the request sent to the one of the service providers is signedby a service provider specific private key of a public/private key pairgenerated by the processor respective to the service provider.
 6. Themethod of claim 5, wherein the service provider specific private key isstored by the processor at a secured storage.
 7. The method of claim 1,further comprising onboarding the service providers associated with thepurchase order of the customer prior to the purchase order.
 8. Themethod of claim 1, wherein the exchanging of the trust artifacts is in acontext respective of the customer.
 9. A system, comprising: a serverthat includes a purchase portal configured to receive a purchase orderfrom a customer, wherein the purchase order includes a service from eachof a plurality of service providers; and a hardware processorconfigured, when receipt of the purchase order is detected, to: inresponse to receiving a triggering event to establish aservice-to-service trust, determine first and second ones of the serviceproviders associated with the purchase order; and in response to adetermination that the service providers have been onboarded, establishthe service-to-service trust relationship between the first serviceprovider and the second service provider in a context of the customer,the processor further configured to: send a first request for a firsttrust artifact to the first service provider and a second request for asecond trust artifact to the second service provider; receive the firsttrust artifact from the first service provider; receive the second trustartifact from the second service provider; send the first trust artifactto the second service provider; and send the second trust artifact tothe first service provider.
 10. The system of claim 9, wherein the firstrequest is signed by a first digital certificate generated by theprocessor respective to the first service provider, wherein the secondrequest is signed by a second digital certificate generated by theprocessor respective to the second service provider.
 11. The system ofclaim 9, wherein the first trust artifact includes a first token sharedby the processor to the second service provider, and wherein the secondtrust artifact includes a second token shared by the processor to thefirst service provider, wherein the first trust artifact is distinctfrom the second trust artifact.
 12. The system of claim 9, wherein inthe first request is based on an authorized application programminginterface between the processor and the first service provider, andwherein the second request is based on a particular authorizedapplication programming interface between the processor and the secondservice provider.
 13. The system of claim 9, wherein the first serviceprovider and the second service provider are trusted by the processorprior to the receipt the purchase order.
 14. The system of claim 9,wherein the first service provider and the second service provider doesnot have a particular trust relationship in a particular context of asecond customer, wherein the second customer did not purchase a firstservice of the first service provider and a second service of the secondservice provider.